OSL – strengths and limitations

[vlado]

Thanks Vlado. I'm more interested in the interpolations used in the VrayVR Mat shader (Sigmoid, Gompertz, Polynomial, etc), rather than the Maya ones. Where would I find the code for that? is it also in the V-Ray SDK samples?

No, it's not in the public SDK. I'm attaching the code here - let me know if you need something else.

Best regards,
Vlado

[sharktacos]

No, it's not in the public SDK. I'm attaching the code here - let me know if you need something else.

Best regards,
Vlado

Awesome, thanks!

[thomashl]

These are issues I brought up in another thread but after exploring OSL for a couple of days, the two big limitations I have found are:

-Inability to output arbitrary values from the shader as render elements. All the closure outputs work but it's often desirable to output arbitrary values.
-Inability of the VRayMtlOSL to accept filename (or "string") parameters. My whole interest in OSL is that I am looking for a way to avoid Maya's dreadful hypershade node connecting mess and want to do everything in the shader. In order to do that, I need to be able to feed texture file names directly into the shader. In fact, in the current implementation (VRay3.0 for Maya), it's unclear what the "file" node passes to the shader: the hypershade indicates that the "outColor" is passed in, but since the shader parameter is a string, that doesn't make sense.

[t.petrov]

Can you tell us what kind of data you want to store in Render Elements from OSL you could not do at the moment?

The problem with the string parameters no allowing you to read files directly might be lifted in a future version.

[re:FORM]

Just a quick question. Would there be any performance hit using an OSL implementation of the vraymtl compared with the native vraymtl?

[vlado]

Just a quick question. Would there be any performance hit using an OSL implementation of the vraymtl compared with the native vraymtl?

It depends. OSL shaders have some overhead, but how much that will affect a render is difficult to say.

Best regards,
Vlado

[sharktacos]

Can you tell us what kind of data you want to store in Render Elements from OSL you could not do at the moment?

I'll second this idea! Basically anything one might put in an OSL closure could be good to have as a render element.

For example my OSL Fabric shader has a sheen component which is written as a closure:

closure color sheen_component = SheenMix * diffuse(bumped_normal, "roughness", Diffuse_roughness);

it would be great to be able to output the sheen as a render element.

To me this gets into the larger idea of being able to use custom AOVs as render elements.

[thomashl]

I am mostly thinking about raw maps and procedural patterns. Maybe there is already a way of doing this that I am not aware of but I am currently working on a shader that is using tons of black and white maps that I am combining and multiplying against the final shading components. I would like to be able to output these control maps on their own in their original form to have further control in the comp.
A concrete example would be a face skin shader that would include black and white isolation maps for nose, lips and ears, and procedural noise for blotchiness. If I could output these controls as basic black and white alphas, I could easily tweak these aspects of my render in the comp.

Also, another issue: Is there a way to group subsets of shader parameters under their own gui elements like you have setup the VRayMtl attribute window. I anticipate needing a whole bunch of parameters and I want to be able to organise how they get laid out in the attribute window.

Lastly (and this is probably not specifically an OSL issue): I would like to be able to pass the name of the current shape name to the shader so it could procedurally pull in a specific texture with a name based on the shape name. I often want to use the same material on multiple shapes names. I understand that the UDMI workflow provides a solution but's unwieldy, particularly on large models. Also, it can complicate larger production workflows quite a bit, because you have to know during modeling and texture painting exactly how you plan to look dev the asset. If different artists are doing these various tasks (often weeks if not months apart), there is no way to anticipate what the needs will be. It's much simpler to just model everything with UV's going from 0 to 1, make sure your maps are named according to the shape they belong to and have the shader somehow read the shape name as a per shape attribute that allows it to pull in the correct map.

[vlado]

You can put any custom user tags in file names, and then define them in the V-Ray user attributes of a particular shape. You don't have to rely on UDIM tags for that purpose.

Best regards,
Vlado

[sharktacos]

Also, another issue: Is there a way to group subsets of shader parameters under their own gui elements like you have setup the VRayMtl attribute window. I anticipate needing a whole bunch of parameters and I want to be able to organise how they get laid out in the attribute window.

OSL has "page" metatata that I believe is intended for this purpose. I don't think metadata has been implemented for OSL in Vray yet, but once it is this would be very useful for organizing a shader's parameters into subsections like all the Vray materials are.

[t.petrov]

OSL has "page" metatata that I believe is intended for this purpose. I don't think metadata has been implemented for OSL in Vray yet, but once it is this would be very useful for organizing a shader's parameters into subsections like all the Vray materials are.

We support some of the widgets and we support metadata, but I don't think we support the "page" tag yet.
Also I'm not really sure if this is something we can implement easily, because of the all the complications when doing Attribute Editor UI.

[sharktacos]

We support some of the widgets and we support metadata, but I don't think we support the "page" tag yet.
Also I'm not really sure if this is something we can implement easily, because of the all the complications when doing Attribute Editor UI.

To my mind, the two most important UI things that are needed for OSL are
1. floats display as sliders (currently they display integer fields so you need to type in the number)
2. colors can take texture map inputs (currently something is either a color or a string which takes a texture but defaults to black)

Next on the list would be
3. drop-down menus,
and then last but not least:
4. some way to add collapsible sections, or labeled separators to the shader or texture to help organize it (the "page" thing)

[EDIT: I think #3 above has been implemented in Vray 3.1, not sure about the others]

[t.petrov]

[EDIT: I think #3 above has been implemented in Vray 3.1, not sure about the others]

I don't think so.

[vlado]

[EDIT: I think #3 above has been implemented in Vray 3.1, not sure about the others]

Only in the 3ds Max version, not for Maya yet.

Best regards,
Vlado

[il_alex]

Hi,

I just discovered this thread and will be watching it closely for procedural textures.

I've created a thread about some issues we've had here:
http://forums.chaosgroup.com/showthr...SL-limitations

Mostly with multiple UVs and needing the ability to drive/keyframe shader input arguments without needing to use callbacks on time/frame changes.

Kind regards
-Alex